In process automation technology, field devices are often used for registering and/or influencing process variables. Examples of such field devices are fill level meters, mass flow measuring devices, pressure and temperature measuring devices, etc., which, as sensors, register the corresponding process variables fill level, flow rate, pressure and temperature.
Serving for the influencing of process variables are so-called actuators, e.g. valves, which alter the flow rate of a liquid in a section of a pipeline, or pumps, which alter fill level in a container.
A large number of such field devices are manufactured and sold by the firm Endress+Hauser.
As a rule, the field devices are connected via a fieldbus (Profibus®, Foundation® Fieldbus, etc.) with control systems or control units. These serve for process control, process visualization, process monitoring, as well as for configuring and parametering of the field devices.
The field devices perform various functions within the process control. For specific standard functions, so-called function blocks with defined communication interfaces are available. These function blocks form with corresponding algorithms, which are executed in the microprocessors of the individual field devices, special application functions. Field devices with microprocessors are referred to as intelligent, or smart, field devices. A significant aspect of the function blocks is that they have defined interfaces and, therewith, can be linked together by, from relatively simple up to very complex, control strategies, which are divided among different field devices.
In the Foundation Fieldbus Specifications, which are publicly available, various standard function blocks are specified. Typical function blocks for field devices are: “Analog Input”; “Analog Output”; “Discrete Input”; “Discrete Output”; “PID-Control”. Along with these basic function blocks, there are also special function blocks: “Analog Alarm”; “Arithmetic”; “Device Control”. Recently, also flexible function block are specified by Foundation Fieldbus (e.g. Supervisory Data Acquisition); these are freely programmable according to the IEC-Standard 61131. Reference is also made to the IEC-Standard 51158, in which, besides various fieldbus systems, also the Foundation® Fieldbus-technology is specified.
In order to change function blocks, the corresponding software code must be replaced in the memory of the field device. This is most often done by replacing the corresponding memory element (EEPROM). Another possibility is to transfer the new program part (i.e. the new software code), e.g. from a laptop, using a service-interface provided on the field device. To this end, however, manufacturer-specific programs, so-called (software-) tools are needed. As a rule, also the transmission protocols are proprietary.
Before a field device can be put in use, it must be configured and parametered. For this, among other things, the loading of the control strategy into the corresponding field devices is necessary. A known application, which enables this, is the SYSCON system of the company, SMAR. With this application, also the correct interconnecting of the individual function blocks, as well as the chronological sequencing of the control strategy, can be tested.
Often in process automation technology, field devices of different manufacturers are used, for whose complete parametering and configuring manufacturer-specific operating programs are required. These are generally also referred to as “tools”, i.e. operating programs (e.g. CommuWin® of the firm Endress+Hauser), which run on computer units, such as e.g. workstations or laptops. In order to enable a universal operating of field devices of different manufacturers, an industry standard, FDT (Field Device Tool)-Specifications, was created by the PNO (Profibus® Nutzerorganisation). Device manufacturers provide their field devices with device-specific software modules, DTMs (Device Type Managers), which encapsulate all data and functions of a field device. Along with this, graphical operating elements are provided at the same time. For execution, the DTMs require, as runtime environment, an FDT frame application (FDT container). Such can be a simple operating program (configuring tool) or a control system application (engineering tool). The FDT Specifications only specify the interfaces, not, however, their implementation.
The underlying software-architecture is based on the Microsoft COM/DCOM technology. DTMs are implemented as COM components (COM server) and are the software interfaces via which the FDT frame application obtains access to the physical field device. The graphical operating elements are implemented as Microsoft ActiveX controls. Via these graphical interfaces, the user obtains a simple access to the physical field device. Besides the field devices, also other devices must be linked into the FDT-frame application. These devices, which, e.g. in the form of gateways and fieldbus adapters, assume communication tasks, require so-called communication-DTMs. A communication-DTM (CommDTM) contains all communication functions and dialogs, via which one can influence and activate the parameters of the network, or bus connection, as the case may be. These elements are normally likewise implemented as ActiveX controls. In the case of the standardized FDT-interface, the CommDTM replaces the currently usual manufacturer-specific configuration software of a network, or fieldbus interface, as the case may be. The communication channel CommChannel corresponds to the driver libraries.
Currently, for operating and configuring field devices and for changing software code in field devices, one needs different, manufacturer-specific programs (tools). Especially the changing of software code in field devices is very complex and can, as a rule, only be done by a technician on-sit, right at the field device. The programs required for this must be, with much effort, produced and tested. If the process automation installation of the user contains field devices of different manufacturers, then different operating programs and different programs for changing software code are needed. This is extremely unsatisfactory for the user.